Building on CHASM: A Study of Using Counts for the Analysis of Static Models of Processes

Process modelling is gaining increasing acceptance by software engineers as a useful discipline to facilitate both process understanding and improvement activities. This position paper builds upon previous work reported at the 1997 ICSE workshop on process models and empirical studies of software engineering (Phalp and Counsell 1997). In the previous paper, we argued that simple counts could be used to support analysis of static process models. We also illustrated the idea with a coupling measure for Role Activity Diagrams, a graphical process modelling notation adapted from Petri Nets. At that time only limited empirical work had been carried out, based upon a single industrial study, where we found high levels of coupling in an inefficient process (a more thorough description may be found in (Phalp and Shepperd 1999)). We now summarise a more recent study, which uses a similar analysis of process coupling again based on simple counts. In the study, we compared ten software prototyping processes drawn from eight different organisations. We found that this approach does yield insights into process problems, which could potentially be missed by qualitative analysis alone. This is particularly so when analysing real world processes, which are frequently more complex than their text book counterparts. One notable finding was that despite differences in size and domain, role types across the organisations exhibited similar levels of coupling. Furthermore, where there were deviations in one particular role type, this led the authors to discover a relationship between project size and the coupling levels within that type of role. Given the simplicity of our approach and the complexity of many real world processes we argue that quantitative analysis of process models should be considered as a process analysis technique

Semantic and Structural Difficulties with the Unified Modeling Language Use-Case Notation version 1.3

A case study was undertaken to examine and apply the UML use-case notation version 1.3. This study shows that the notation is open to interpretation and the semantics of the use-case relationships are confusing. The attempt to bolt on the object-oriented inheritance structure to the use-case notation is shown to cause problems with users

Analysing Process Models Quantitatively

Over the years, there has been much interest in modelling processes. Processes include those associated with the development of software and those business processes that make use of software systems. Recent research in Systems Engineering for Business Process Change highlights the importance of modelling business processes in order to evolve and maintain the legacy systems that support those processes. Business processes are typically described with static (diagrammatic) models. This paper illustrates how quantitative techniques can facilitate analysis of such models. This is illustrated with reference to the process modelling notation Role Activity Diagrams (RADs). An example process, taken from an investigation of the bidding process of a large telecommunications systems supplier, is used to show how a quantitative approach can be used to highlight features in RADs that are useful to the process modeller. We show how simple measures reveal high levels of role coupling and discrepancies between different perspectives. Since the models are non-trivial — there are 101 roles and almost 300 activities — we argue that quantitative analysis can be a useful adjunct for the modeller

An Empirical Investigation of the Utility of ‘pre-CIM’ models

that, by allowing a variety of stakeholders to take part in modelling, projects will be both more efficient than traditional approaches and will produce software that meets the needs of those stakeholders. This will be facilitated by transforming initial (CIM), models to design (PIM) and implementation (PSM). However, it follows that to gain fully from this strategy the initial models, which are the major driver for communication and validation of requirements and business needs, must be appropriate to this usage. The VIDE project was an EC funded project which produced a successful model driven development tool-set, incorporating a variety of modelling capabilities, at each stage of the MDA process. Aside from support for model transformations, one of the motivations for VIDE was to provide accessible models for those stakeholders representing the client (or business) who may not share the modelling perspective and experience of software engineers. This paper reports upon an empirical study which attempts to assess whether our proposed ‘pre-CIM’ models provide a more palatable starting point for users. In brief, our results suggest that the pre-CIM notation provides an accessible starting point for modelling, and enhance the modeller’s experience whilst also suggesting that the use of the notation may have a positive impact on the quality of subsequent models

The application of metrics to industrial prototyping processes: An empirical study

A key problem in the development of information systems is understanding features of the development process. To this end, in recent years, considerable interest has been focused on modelling processes. In this paper, the results of an empirical investigation into the use of prototyping in information systems development is described. Nine prototyping processes across eight different sites of varying size were analysed and data relating to each process collected. The notation of Role Activity Diagrams (RADs) was used to capture each of the nine processes. Analysis of the interactions in each process revealed that the project manager interacted with the prototyper far more often in large developments than in small or medium-sized developments. However, significantly more interactions between the project manager and end-user were found in small-sized developments than for any other sized site. The study demonstrates how measures of business models can aid analysis of the process rather than the product and highlights the need for more empirical investigation into this and other facets of the development process. A number of lessons have been learnt from our analysis; these we also explain

Enabling Multi-Stakeholder Cooperative Modelling in Automotive Software Development and Implications for Model Driven Software Development

One of the motivations for a model driven approach to software development is to increase the involvement for a range of stakeholders in the requirements phases. This inevitably leads to a greater diversity of roles being involved in the production of models, and one of the issues with such diversity is that of providing models which are both accessible and appropriate for the phenomena being modelled. Indeed, such accessibility issues are a clear focus of this workshop. However, a related issue when producing models across multiple parties,often at dierent sites, or even dierent organisations is the management of such model artefacts. In particular, different parties may wish to experiment with model choices. For example, this idea of prototypingprocesses by experimenting with variants of models is one which has been used for many years by business process modellers, in order to highlight the impact of change, and thus improve alignment of process and supporting software specications. The problem often occurs when such variants needed to be merged, for example, to be used within a shared repository. This papers reports upon experiences and ndings of this merging problem as evaluated at Bosch Automotive. At Bosch we have dierent sites where modellers will make changes to shared models, and these models will subsequently require merging into a common repository. Currently, this work has concentrated on one type of diagram, the class diagram. However, it seems clear that the issue of how best to merge models where collaborative multi-party working takes places is one which has a significant potential impact upon the entire model driven process, and, given the diversity of stakeholders, could be particularly problematic for the requirements phase. In fact, class diagrams can also be used for information or data models created in the system analysis step. Hence, we believe that the lessons learned from this work will be valuable in tackling the realities of a commercially viable model driven process